T2147-908627 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

re application of: 

Anne KASZYNSKI & Jacques ABILY 
Serial No.: 10/627,976 
Filed: July 28, 2003 



For: Method For Functional Verification Of An 
Integrated Circuit Model For Constituting A 
Verification Platform, Equipment Emulator 
And Verification Platform 



Examiner: 



Group Art Unit: 



Corresponding to: 
French Patent 
Application FR 02 09691 



McLean, Virginia 



COMPLETION OF 
CLAIM FOR BENEFIT OF FILING DATE 
OF PRIOR FOREIGN APPLICATION 

Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 

Sir: 

In the matter of the above-identified application, a claim is hereby made under 
the provisions of 35 U.S.C.. 1 1 9 for the benefit of the filing date of the corresponding 
French application No 02/09691 filed July 30, 2002, which is referred to in the 
Declaration of the present case. 

A certified copy of said French application is enclosed herewith 

Respectfully submitted, 
MILES & STOCKBRIDGE P.C. 



Date 



March 25. 2004 




Edward J. Kondracki 
Registration No. 20,604 
Customer No. 181 



Miles & Stockbridge, P.C. 
1751 Pinnacle Drive, Suite 500 
McLean, Virginia 22102-3833 
Tel.: (703) 903-9000 



TYSO0 1 :9200 1 28v 1 |T2 1 47-908627|9/23/2003 



IN 5 ! 



I INSTITUT 
NATIONAL DE 
LA PROPRIETE 
INDUSTRIELLE 



BREVET D' INVENTION 



CERTIFICAT D'UTILITE - CERTIFICAT D'ADDITION 



COPIE OFFICIELLE 



Le Directeur general de I'lnstitut national de la propriete 
industrielle certifie que le document ci-annexe est la copie 
certifiee conforme d'une demande de titre de propriete 
industrielle deposee a I'lnstitut 

Fait a Paris, le ... 3 0 JUIL 2003 _ _ 



Pour le Directeur general de I'lnstitut 
national de la propriete industrielle 
Le Chef du Departement des brevets 




Martine PLANCHE 




INDUSTRIELLE www.inpi.fr 



OB 267/141102 



ETABLISSEMENT PUBLIC NATIONAL CREE PAR LA LOI N» 51-444 DU 19 AVRIL 1951 



1er depot 



INPI 



iRousmiitii 

26 bis. rue de Saint Petersbourg 
75800 Paris Cedex 08 

Telephone : 01 53 04 53 04 Telecopie : 01 42 94 86 54 



™ ,S£ 3tTJuiL 2002 



DATE 

ueu 75 IN Pi PARIS 



N* D* ENREGI STREMENT 
NATIONAL ATTRIBUE PAR L'lNPI 
DATE DE DEPOT ATTR1BUEE 
PAR t INPl 



Vos references pour ce dossier 

ijacullaiij) BULL3945/FR 



4 Reserve a I'lNPI \ 



BREVET D'INVENTION <Jjg> 

CERTIFICAT D'UTILITE tr tmvm 

Code de la propriete intellectueite - Lrvre VI 

requete EN DEUVRANCE 1/2 

Cet imprime est a remplir llsiblement a I'encre noire oesxaw^eosM 



0209691 
3 0 JUIL. 2002 



J NOM ET ADRESSE DU DEMANDEUR OU DU MANDATAIRE 
A QUI LA CORRESPONDANCE DOIT ETRE ADRESSEE 

• 

CABINET DEBAY 
126 ELYSEE2 

78 1 70 LA CELLE SAINT CLOUD 



Confirmation d'un depot par telecopie Q N° attribue par I'lNPI a la telecopie 



3 NATURE OE LA DEMANDE 



Demande de brevet 



Cochez Pune des 4 cases suivantes 



Demande de certificat d'utilite 



IT 



Demande divisionnaire 

Demande de brevet initiate 
ou demande de certificat d'tdilite initiate 



□ 

N° 



Date 
Date 



Z_ /... 

/ 



Transformation d'une demande de 
brevet europeen Demande de brevet initiate 



□ 

N° 



Date 



| TITRE DE L'lNVENTION (200 caracteres ou espaces maximum) 

Procede de verification fonctionnellc d'un modele dc circuit integre pour constituer une plate-forme de verification, 
equipement emulateur et plate-forme de verification. 



DECLARATION DE PRIORITY 
OU REQUETE DU BENEFICE DE 
LA DATE DE DEPOT D'UNE 
DEMANDE ANTERIEURE FRANpAISE 



Q DEMANDEUR 



Nom ou denomination sociale 



Prenoms 



Forme juridique 



N° SIREN 



Code APE-NAF 



Adresse 



Rue 



Code postal et ville 



Pays 



Nationality 



Pays ou organisation 
Date J... L... 



Pays ou organisation 

Date ! /_ / - J 

Pays ou organisation 

Date 1 / /. _ _i 



N° 



| — | s'il y a d'autres prtorftes, cochez la case et utilisez Pimprime" «Suite» 



| — | s f il y a d'autres demandeurs, cochez la case et utilisez PimprimS «SuHe» 



BULL S.A. 



Societe Anonyme 



6 -4 2 0 5 8 .7 3 -9 



68, route de Versailles 



78430 



LOUVECIENNES 



FRANCE 



Franc aise 



N° de telephone (facuiiatif) 



N° de telecopie (facultatif) 



Adresse electronique (facultatif) 



1 er depot 



INPI 



■ mnituj 

WAttOKAL at 
LA F*OM»Ul« 
IMOUBT*t(LLr 



BREVET D'INVENTION 

CERTIFICAT D'UTILmt 

REQUETE EN DEUVRANCE 2/2 



1 |R6serv6 a I'lNPI 

IStfSJUlL 2002 



ueu 75 IN Pi PARIS 

N° D'ENREGISTREMENT 0209691 

NATIONAL ATTRIBUS PAR L'INPI 



Vos references pour ce dossier : 

(facultatij) 


BULL3945/FR 


O MANDATAIRE 




Nom 


DEBAY 


Prenom 


Yves 


Cabinet ou Societe 


CABINET DEBAY 


N °de pouvoir permanent et/ou 
de lien contractuel 


CPI 92-1066 


Adresse 


Rue 


126 ELYSEE 2 


Code postal et ville 


78 1 70 | LA CELLE SAINT CLOUD 


N° de telephone (Jacultatif) 


01.39.18.46.24 


N° de telecople (Jacultatif) 


01.39.18,67.08 


Adresse electronique (facultatij) 


Cab.Debay@wanadoo.fr 


Q INVENTEUR (S) 




Les inventeurs sont les demandeurs 


pOui 

f~*1 Non Dans ce cas fournir une designation d'inventeur(s) separee 


Q RAPPORT DE RECHERCHE 


Uniquement pour une demande de brevet (y compris division et transformation) 


Etablissement immedtat 
ou etablissement differe 


E 
□ 


Paiement echeionne de la redevance 


Paiement en trois versements, uniquement pour les personnes physiques 

□Oui 
□Non 


Q REDUCTION DU TAUX 
DES REDEVANCES 


Uniquement pour les personnes physiques 

CZlRequise pour la premiere fois pour cette invention (joindreini avis de non~impt>sition) 

CZlRequise anterieurement a ce depot (join fire une copie de la decision dad mission 
pour cette invention ou indiquer sa reference) : 




Si vous avez utilise I'imprime «Suite» f 
indiquez ie nombre de pages joirites 






EE SIGNATURE DU DEMANDEUR 
OU DU MANDATAIRE 

(Nom et qua lite du sign ata ire) 

Y. DEB AY Mandataire (CPI 92- 1 066) ^sg^^A^ 


VISA DE LA PREFECTURE 
OU DE L'INPI 



La ioi n°78-17 du 6 janvier 1978 relative a I'informatique, aux fichiers et aux liberies s'applique aux reponses faites a ce formulaire. 
EHe garantit un droit d'acces et de rectification pour les donnees vous concernant aupres de I'lNPI. 



1 er depot 



Procede de verification fonctionnelle d*un modele de circuit integre 
pour constituer une plate-forme de verification, equipement emulateur 

et plate-forme de verification. 

La presente invention concerne un procede de verification 

5 fonctionnelle d'un modele logiciel d'un circuit integre pour constituer une 
plate-forme de verification et la plate-forme de verification ainsi constitute. 

L'invention s'applique, d'une part, lors de la phase de verification de la 
conception des specifications particulieres d'un circuit integre repondant aux 
besoins d'un industriel utilisateur, usuellement appele ASIC (Application 

10 Specific Integrated Circuit), mais, egalement, dans la phase de mise au point 
de I'ensemble constitue par le composant physique ASIC et le programme 
d'application execute par I'ASIC composant physique. 7- 

Dans le domaine des circuits integres, il existe deux types de circuits, 
les circuits dits classiques et les circuits specifiques dits ASICs., Les 

15 fabricants de circuits integres classiques presentent des catalogues de 
circuits standards dont les references designent chacune une fonbtion 
particuliere normalisee. Pour des applications specifiques, rindustriel 
utilisateur de circuits integres prefere faire developper des circuits 
specifiques dits ASICs. 

20 Les differentes etapes de developpement des ASICs sont les 

suivantes : 

- definition d'une specification fonctionnelle ; 

- modelisation (definie ci-apres) en un langage de type HDL de 
description materielle de TASIC et verification fonctionnelle de la 

25 conception associee a cette modelisation ; 

- fabrication technologique par le fondeur de circuits integres ; et 

- mise au point materielle du circuit 

La definition de la specification fonctionnelle est : Telaboration des 
documents decrivant les fonctionnalites couvertes par I'ASIC. 
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Elle comprend : 

• d'une part, les specifications de niveau systeme decrivant : 

- la visibility fonctionnelie des registres de I'ASIC ; 

- le protocole de coherence assurant I'integrite des donnees, dans 
5 le cas d'un systeme a memoire partagee ; 

- les specifications des interfaces externes des composants ; 

• et, d'autre part, les specifications decrivant les choix d'implementation 
de I'ASIC. 

La moderation de type HDL de I'ASIC consiste en la description des 
10 equations logiques booleennes rendant compte de son comportement 
conformement a sa specification. Le langage de type HDL utilise est un 
langage dedie a la description des objets materiels du circuit integre 
(Hardware). II contient les primitives de description des composants avec 
leurs signaux d'interface ainsi que des elements memorisant, tels que 
is registres ou memoires. 

Le niveau de description de type HDL sert de point d'entree au 
processus de generation automatique aboutissant in fine a la fourniture de 
masques pour le processus technologique de fabrication du circuit. 

La verification fonctionnelie de la conception de I'ASIC a pour objectif 
20 de verifier la conformite du comportement du modele de type HDL de I'ASIC 
a sa specification fonctionnelie en amont du lancement du processus 
technologique. 

Une fois la logique de I'ASIC stabilisee, un processus quasi- 
automatique applique a la description de type HDL de I'ASIC permet de 
25 generer la liste des cellules physiques constituant I'ASIC et d'elaborer ies 
masques livres au fondeur (fabricant d'ASIC) pour la fabrication du circuit. 

La fabrication technologique du circuit est le processus chimique 
permettant, a partir des masques, de produire les echantillons physiques des 
circuits. 

30 Des tests non fonctionnels sont appliques en sortie de fabrication pour 

valider que le processus technologique s'est bien deroule, et selectionner les 
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echantillons bons candidats a etre montes dans les boTtiers pour la phase 
suivante de validation. 

La mise au point materielle est la premiere phase de validation des 
ASICs dans leur environnement systeme reel apres montage des 
5 echantillons dans les boTtiers et connexion sur les cartes. 

Au stade de la fabrication, le fabricant d'ASIC n'est pas en mesure de 
verifier que le modele fonctionnel de I'ASIC fourni par I'industriel utilisateur ne 
comportait pas d'erreur de conception. II est simplement en mesure de 
confirmer la conformite de la puce de silicium avec le schema fonctionnel 
10 demande. 

Un des buts de invention est de permettre a Tindustriel utilisateur de 
I'ASIC, avant la realisation physique du circuit de verifier I'exactitude du 
modele fonctionnel qu'il va fournir au fondeur (fabricant d'ASIC). 

Compte tenu du cout eleve d'etude de I'ASIC, il faut valider le plus 

15 completement possible le schema theorique resultant de la specification 
fonctionnelle pour eliminer toute erreur subsistante avant de lancer I'etude du 
dossier de fabrication de I'ASIC par le fondeur. C'est pourquoi le niveau de 
description du modele de I'ASIC est utilise pour la verification fonctionnelle 
de la conception de I'ASIC en amont du lancement du processus 

20 technologique de fabrication. La verification a pour objectif de verifier la 
conformite du comportement du modele de type HDL de I'ASIC a sa 
specification fonctionnelle. 

Avec la complexite croissante des ASICs liee a leur haut degre 
d'integration et le cout eleve de leur fabrication, la verification fonctionnelle 

25 pendant la phase de conception du circuit occupe une place preponderate 
(plus de 60%) qui tendra a s'accroTtre encore de fagon notable dans les 
annees a venir. 

D'olj la necessite de disposer d'une methodologie solide de 
verification fonctionnelle. 
30 C'est dans ce contexte que se situe Tun des interets de I'invention 

proposee. 
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Lorsque des echantillons de I'ASIC composant physique ont ete 
fabriques, I'industriel utilisateur valide la foncttonnalite de Tensemble ASIC 
composant physique-programme duplication execute par I'ASIC et verifie 
qu'ils repondent au cahier des charges de I'ensemble. Au cours de cette 
5 phase, les ASICs montes dans leurs boTtiers sont connectes sur leur carte a 
leur environnement systeme reel pour constituer une plate-forme de 
validation. 

L'invention proposee peut egalement trouver son application dans 
cette phase. 

10 Pour verifier fonctionnellement les diverses parties constitutives du 

modele de I'ASIC, telles qu'unite arithmetique, memoires, compteurs, logique 
combinatoire, routeur a antememoire et autres, on peut les activer 
separement, dans la mesure ou chacune est directement accessible depuis 
les entrees/sorties simulees de I'ASIC et suffisamment independante des 

is autres. On verifie alors que la partie consideree est confornne a un modele de 
fonctionnement logique defini au cahier des charges. II faut aussi verifier 
Tinterfonctionnement des diverses parties, en activant simultanement 
plusieurs de ces parties. II faut en particulier effectuer des tests 
combinatoires entre les parties pour tenter de verifier Tabsence de 

20 configurations, non prevues lors de la conception du modele fonctionnel, 
d'etats des diverses parties respectives, qui seraient susceptibles de 
conduire a un fonctionnement defectueux, par exemple un blocage mutuel 
entre deux parties. II est aise de comprendre que le nombre des tests 
combinatoires croTt done beaucoup plus rapidement que le nombre de 

25 circuits ou transistors de TASIC. En outre, la presence de memoires dans 
TASIC, qui peuvent commander certains des circuits de ce!ui-ci, entraTne le 
fait que Tetat global des diverses sorties, pour des entrees presentant un 
meme etat global a un instant determine, depend de Phistorique de la 
succession des etats d'entree precedents. 

30 La mise au point de la programrnation de tests fonctionnels est longue 

et couteuse. En pratique, cette mise au point s'effectue en utilisant le modele 
de PASIC. En d'autres termes, des que le modele est conQu, on peut alors 
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chercher a detecter les deux types d'erreurs suivants : les erreurs residuelles 
du cahier des charges, et les erreurs ou lacunes des programmes de 
validation fonctionnelle de I'ASIC ou des programmes applicatifs. Ce cumul 
de taches reagissant les unes sur les autres, est evidemment lourd a gerer, 
et il entraTne des couts et des retards. 

La pr6sente invention vise a limiter un ou plusieurs de ces 
inconvenients. 

A cet effet, I'invention concerne tout d'abord un precede de verification 
fonctionnelle d'un modele logiciel d'un circuit integre a la demande (ASIC), 
en langage de bas niveau (tel que par exemple de type HDL) traitant de 
fagon separee i'etablissement du modele et la mise au point des tests de 
verification fonctionnelle a appliquer au modele du circuit pour constituer une 
plate-forme de verification comportant les deux etapes suivantes : 

- constitution d'un emulateur autonome de circuit obtenu ?en 
remplagant le modele en langage de bas niveau (de type HDL) de description 
physique du circuit en projet a valider, par une description abstraite de haut 
niveau (par exemple C ++ ) generant des structures de donnees de reponse 
conformes a la specification fonctionnelle du projet en fonction des stimuli 
regus, ce mode etant dit « mode emission », e 

- integration du modele logiciel en langage de bas niveau (de 
type HDL) du circuit resultant du projet dans la plate-forme de verification, et 
branchement de la configuration de simulation autonome, precedemment 
validee, en parallele sur les interfaces du modele logiciel du circuit, et du 
branchement d'un emulateur d^nvironnement, et 

- utilisation de plate-forme comme reference pour la validation 
des donnees de reponses emises par le modele logiciel du circuit, ce mode 
etant dit « mode verification ». 

Le programme de validation de fonctionnalite peut ainsi etre mis au 
point en temps masque, en parallele avec ['elaboration du dossier de 
fabrication de TASIC. Ensuite, un modele de ce dernier ayant ete elabore, il 
suffit de disposer en memoire de la sequence d r entree de test de validation 
de fonctionnalite, puisque Temulateur represente la specification 
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fonctionnelle et fournit les stimuli de sortie en reponse a cette sequence 
d'entree, a titre de reference. 

L'emulateur constitue ainsi, fonctionnellement, une sorte de 
bibliotheque qui contiendrait tous les etats de sortie possibles du modele de 
I 'ASIC, predits d'apres les reponses de la specification fonctionnelle a tous 
les stimuli d'entree possibles fournis par un emulateur d'environnement La 
fourniture de stimuli d'entree par l'emulateur d'environnement equivaut a un 
adressage du contenu de la bibliotheque pour selectionner I'etat ou stimuli de 
sortie correspondant predit. Cette bibliotheque pourrait done etre une simple 
memoire, constituant une table de decision contenant la total ite des etats de 
sortie predits, adressee pour decider que I'un de ses etats est celui qui 
convient. Toutefois, la taille memoire necessaire serait en general excessive, 
et il est alors preferable d'elaborer en temps reel la prediction des stimuli de 
sortie, d'apres la specification fonctionnelle. 

II est a noter que le procede de Tinvention n'est pas limite a des ASICs 
purement numeriques, car on peut emuler des circuits analogiques, le cas 
echeant, au moyen d f une unite de calcul numerique et d'un convertisseur 
numerique / analogique. 

Dans un mode de mise en oeuvre, un utilisateur elabore, au moyen 
d'un systeme de traitement de donnees, la configuration de simulation 
autonome correspondant au modele logiciel de TASIC au moyen de la 
specification fonctionnelle, 

• Putilisateur ecrit, a partir de la specification fonctionnelle, et memorise, 
dans une plate-forme de test de modeles de circuits integres, un 
programme de test du modele de TASIC, comportant des sequences 
de stimuli d f entree a fournir au modele logiciel de I'ASIC, auxquelles la 
configuration de simulation autonome fait correspondre, en fonction de 
la specification fonctionnelle, des sequences de stimuli de sortie, 

• I'utilisateur relie ensemble, et active, la configuration de simulation 
autonome et la plate-forme de test, et 
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• il observe les stimuli de sortie du modele de type HDL de I'ASIC pour 
valider fonctionnellement rensemble constitue par le modele logiciel 
du circuit ASIC et le programme de test de validation, et ainsi valider 
le modele logiciel par rapport a la specification fonctionnelle. 
5 Avantageusement, la configuration de simulation autonome 

communiquant avec I'utilisateur pour commander Pactivation de modeles, 
prealablement etablis et memorises, de sequences de stimuli d'entree definis 
dans un langage de programmation de haut niveau, et commande Pactivation 
de programmes associes de validation progressive de sequences de test 
10 determinees a partir des modeles. 

Grace a la modularity du systeme et a la progressivite de la mise au 
point, Putilisateur peut ainsi s'appuyer, au depart, sur des modeles de test de 
validation fonctionnelle existants, a priori au point, qu'il complete ou adapte 
au cas particulier de I'ASIC. ? 
15 L'utilisateur peut ecrire et fournir la specification fonctionnelle^dans un 

langage de programmation de bas niveau, specifiant des modeles 
fonctionnels de circuits. 

II peut aussi, dans un mode mixte, fournir la specification fonctionnelle 
sous la forme d'un programme en langage de bas niveau, de modeles (de 
20 type HDL) fonctionnels de circuits, et d'un programme en langage de haut 
niveau, de modeles fonctionnels ((C++) symboliques de circuits), et 
commander la configuration de simulation autonome (1) pour effectuer une 
co-simulation par synchronisation d'execution des deux programmes de 
specification. 

25 Les diverses parties de la specification fonctionnelle peuvent ainsi etre 

ecrites dans le langage qui convient le mieux, et en particulier qui evite les 
pertes de temps pour definir les stimuli de sortie. 

Avantageusement, la plate-forme de test verifie que les reponses du 
modele logiciel de I'ASIC sont situees dans des plages de temps de reponse 
30 specifiees dans la specification fonctionnelle. 

L'invention concerne aussi une plate-forme de verification de modele 
logiciel de circuit integre a la demande, caracterise par le fait qu'elle 
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comporte des moyens de traitement de donnees permettant a un client de 
selectionner des modeles de test engendrant des stimuli d'entree de I'ASIC, 
ces moyens de traitement etant agences pour lire des elements de 
specification fonctionnelle de I'ASIC, et comportant des programmes 
5 agences pour elaborer un programme de test de validation fonctionnelle 
constitue de stimuli de sortie a partir des stimuli d'entree et des elements de 
specification fonctionnelle. 

Avantageusement, la plate-forme de verification comporte une 
bibliotheque de modeles fonctionnels de blocs de circuits pour ASIC et des 

10 moyens de selection des modeles par un fichier de definition de la 
configuration, pour constituer un modele correspondant a la specification 
fonctionnelle de I'ASIC integre a la definition de son environnement. 

II peut y etre prevu, dans une liaison le reliant au client, deux circuits 
en serie d'adaptation de langage de programmation agences pour 

15 transformer des commandes en langage de haut niveau (C ++ ), utilise par le 
client, en commandes en langage de bas niveau (de type HDL), exploitables 
par le modele de I'ASIC, et pour, respectivement, retransformer les 
commandes en langage de bas niveau en commande en langage de haut 
niveau. 

20 Avantageusement, la plate-forme de verification comporte des moyens 

d'executer ses traitements en meme temps que la simulation qu'elle peut 
interrompre des la detection d'une erreur au moment meme de ('apparition 
de I'erreur. 

Selon une autre particularite, les elements de specification 
25 fonctionnelle sont constitues d'une table de verite, ou de comportement, 
correspondant aux fonctions des diverses parties ou divers elements de 
circuit fonctionnels du modele logiciel de I'ASiC, et des plages de retard de 
propagation a respecter entre chaque entree et chaque sortie. 

Selon une autre particularite, la plate-forme de verification dispose 
30 d'une antememoire pour memoriser les blocs utilises par les noeuds d'apres 
leur adresse et des moyens de gerer, pour une adresse utilisee par un ou 
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plusieurs noeuds, un vecteur de presence avec un temoin de presence par 
noeud. 

Selon une autre particularite, les programmes sont orientes objet et 
I'emulateur est structure en un ensemble de classes permettant de gerer une 
5 collection d'hypotheses d'execution d'une transaction sur un bloc memoire du 
modele logiciel, et de gerer egalement les transactions en collisions, c'est-a- 
dire utilisant un meme bloc memoire. 

Selon une autre particularite, les algorithmes des programmes de 
I'emulateur realisent les fonctions suivantes : generation des predictions, 
10 d'elimination des predictions, re-ajustement de mauvaise prediction, 
reduction du nombre d'hypotheses valides et terminaison de collisions. 

Selon une autre particularite, la plate-forme de verification est utilisee 
en emulateur de circuit routeur, de circuit a antememoire ou de circuit routeur 
a antememoire. 

15 Seion une autre particularite, la plate-forme de verification permet de 

tester un modele logiciel de circuit integre a la demande (ASIC), caracterisee 
en ce quelle comporte un emulateur d'AStC pour commander un 
comparateur prevu pour recevoir des valeurs generees par le modele logiciel 
de circuit ASIC teste, sur reception de stimuli envoyes par au moins un circuit 

20 generateur de stimuli, memorisant le programme de test, une interface de 
traduction des stimuli d'un langage elabore vers un langage de bas niveau 
correspondant a celui du modele logiciel, et des moyens de validation de la 
verification en cas de detection de collision par le comparateur. 

Dans une forme de realisation, les moyens de selection de la reponse 

25 a des stimuli dependants de la constitution des circuits testes. sont constitues 
d'un modele elabore grace a des moyens de selection, parmi une 
bibliotheque, de modeles fonctionnels associant, a chacun des modeles, les 
reponses a un stimulus donne, le modele correspondant a la constitution du 
circuit a tester. 

30 La plate-forme peut comporter des moyens de memorisation des 

reponses ainsi selectionnees pour constituer un modele de test a appliquer 
au circuit teste lors de la reception de stimuli. 
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Selon une autre particuiarite, chaque transaction est constitute, au 
niveau de chaque interface, d'un paquet requete et d'un ou plusieurs paquets 
reponses associes, dont les valeurs des parametres et/ou les contraintes 
temporelles d'emission des paquets peuvent etre forcees a partir du 
5 programme de test fonctionnel execute par I'emulateur de I'environnement, 
qui traduit de fagon adequate I'ensemble de ces parametres lors de 
remission des paquets aux bornes du modele logiciel du projet. 

Selon une autre particuiarite, la generation des predictions est 
effectuee par I'emulateur du circuit sans avoir a prelever d'informations 
10 supplementaires sur le fonctionnement interne du circuit en projet 

^invention sera mieux comprise a Paide de la description suivante 
d'un mode de realisation de I'invention et de mise en oeuvre du procede de 
invention, en reference au dessin annexe, sur lequel : 

- la figure 1 est un diagramme fonctionnel representant un emulateur de 
15 circuit integre ASIC represents avec la gestion d'une interface dans un 

emulateur d'environnement pouvant comporter une ou plusieurs interfaces, 

- la figure 2 represente le meme emulateur, branche logiquement en parallele 
sur le modele logiciel de circuit ASIC a tester, ou emulateur du circuit en 
projet en mode emetteur, represente avec la gestion d'une interface dans un 

20 emulateur d'environnement pouvant comporter une ou plusieurs interfaces, 

- la figure 3 est une variante de la figure 2 appliquee a un modele de circuit a 
deux noeuds, et 

- la figure 4 represente ('architecture interne d'un verificateur. 

Avant de decrire I'invention il est necessaire, pour sa bonne 
25 comprehension, de poser un certain nombre de definitions utilisees par la 
suite. 

Un emulateur est un programme ou un dispositif permettant de 
reproduire sur ses interfaces externes le meme fonctionnement que le(s) 
circuit(s) ou modeles de type HDL de circuit au(x)quel(s) il se substitue. 
30 Dans ce document, Tinvention est appliquee au cas d f un circuit integre 

de type routeur avec antememoire car reconnu comme etant le cas le plus 
complexe. Dans la suite, le mot ROUTEUR designe : 
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- soit le modele de type HDL du circuit en projet, 

- soit i'emulateur du circuit en projet ("Design") en mode emission. 

La programmation objet a permis : d'une part, de structurer I'emulateur 
de ROUTEUR en un ensemble de classes specialisees, d'autre part, de 
5 simplifier le traitement par la localisation et la specialisation de ces 
traitements a chaque instance de chaque classe, comme nous le verrons par 
la suite. 

Dans le contexte de la simulation logicielle ("Software"), la plate-forme 
de verification est constitute de Tensemble des modeles de generation de 
10 stimuli et des modeles d'observations aux interfaces du circuit en projet ou 
en conception ("Design") qui est a valider. Ces modeles d'observations 
constituent un emulateur de I'environnement du circuit en projet ("Design"). 

La methodologie de verification de la plate-forme de I'inventioa fait 
egalement usage d'un emulateur du projet ("Design") pouvant fonctiormer 
15 suivant 2 modes : 

- Le mode controleur ("Checker") dans lequel I'emulateur du 
circuit en projet ("Design") sert de reference pour, la 
validation des reponses du circuit en projet ("Design") en 
fonction des stimuli d'entree appliques par I'emulateur 

20 d'environnement, ou des reponses de I'emulateur du circuit 

en projet en mode emetteur. 

- Le mode emetteur dans lequel I'emulateur du circuit en 
projet ("Design)" se substitue au projet ("Design") lui-meme 
dans des configurations de simulation autonomes pour la 

25 mise au point de la plate-forme de verification sans avoir a 

utiliser le modele de type HDL du projet ("Design"). 
L'ensemble des emulateurs (emulateur de circuit et emulateur 
d'environnement) constituant la plate-forme de verification sont des modeles 
objet ecrits en C ++ connectes aux interfaces du modele en langage de type 
30 HDL de bas niveau du circuit en projet ("Design") via des adaptateurs 
d'interface en type HDL. Le degre d'utilisation du langage evolue par rapport 
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au degre d'utilisation du langage de bas niveau type HDL varie selon I'etat 
d'avancement de mise au point des emulateurs. 

En general, on part d'une specification fonctionnelle de circuit 
contenant une majorite de langage C ++ et juste des interfaces en langage de 
type HDL pour aboutir a un modele logiciel comportant une majorite de 
langage de type HDL de bas niveau et quelques interfaces en C ++ . 
devolution du modele logiciel en langage de type HDL du circuit en cours de 
developpement se fait progressivement en utilisant des modeles 
intermediates mis au point contenant une proportion plus equilibree de 
langage evolue par rapport a la proportion de langage de type HDL. 

Dans les adaptateurs d'interface, les echanges entre C ++ et de type 
HDL sont abstraits en evenements. Les evenements rendent aussi bien 
compte des echanges arbitraires de donnees contenues dans les paquets 
que des changements de valeurs sur les signaux de controle. Le paquet est 
la granularite de traitement atomique des modeles abstraits C ++ appartenant 
au niveau de description (dit protocole) des interfaces. 

En mode controleur ("Checker"), I'emulateur du circuit en projet 
("Design") effectue ses controles en temps reel, c'est-a-dire que ses 
traitements s'executent en meme temps que la simulation qu'il peut 
interrompre des la detection d'une erreur au moment meme de son 
apparition. Cette caracteristique interessante du point de vue exploitation 
permet d'eviter de generer des fichiers de trace pendant I'exploitation 
normale et de generer les informations necessaires au diagnostique que 
lorsqu'il y a erreur, limitant ainsi la lourdeur des traitements posterieurs dits 
de post-processing. 

En mode controleur ("Checker"), I'emulateur du circuit en projet 
("Design") peut construire ses controles sur la seule base des specifications 
fonctionnelles de niveau systeme sans prelevement d'informations 
supplementaires sur le fonctionnement interne du circuit en projet ("Design"). 
Cette propriete remarquable permet son application a 2 types de contextes 
differents : 



1er depot 

13 



- Le contexte de simulation C + 7HDL du circuit en projet ("Design"), 
dans lequel I'emulateur du circuit en projet ("Design") est alors 
connecte a I'ensemble des interfaces du modele logiciel en 
langage de type HDL de bas niveau du circuit en projet 

5 ("Design"), sur lesquels il preleve les echanges de paquets des 

modeles d'observations via les adaptateurs d'interface ; 

- En execution C ++ seule, a partir de traces prelevees aux interfaces 
du modele logiciel du circuit en projet ("Design"), ces traces etant 
eventuellement reformatees sous forme de paquets avant d'etre 

10 rejouees en autonome par I'emulateur du circuit en projet 

("Design"). 

Les traces prelevees aux bornes du circuit en projet ("Design") a valider 
peuvent etre d'origines differentes : ; v; 

- Dans le contexte de la verification fonctionnelle, elles proviennent 
is de la memorisation des paquets echanges au cours sd'une 

simulation anterieure. Les traces peuvent se presenter, soit sous 
forme textuelle, soit sous forme de structures C ++ dites fibres 
stockees dans une base. 

- Dans le contexte de la mise au point materielle, elles proviennent 
20 du prelevement des stimuli aux bornes de I'echantillon physique 

du circuit Les stimuli abstraits en evenements sont reformates 
sous forme de paquets avant d'etre injectes a I'emulateur du projet 
("Design)" pour diagnostic en execution autonome. 
Les tests fonctionnels commandent le parametrage des paquets transmis au 
25 projet ("Design") cible via son environnement : 

- Dans le contexte de la verification fonctionnelle, les tests 
fonctionnels s'appuient sur I'interface programmatique applicative 
(API) de I'emulateur de I'environnement du circuit en projet 
("Design) a valider pour commander directement et precisement la 

30 succession des transactions a transmettre au projet pour 

execution. Chaque transaction est constitute au niveau de chaque 
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interface, d'un paquet requete et d'un ou plusieurs paquets 
reponses associes. Aussi bien les valeurs des parametres que les 
contraintes temporelles d'emission des paquets peuvent etre 
forcees a partir des tests. L'emulateur de I'environnement traduit 
de fagon adequate I'ensemble de ces parametres lors de 
remission des paquets aux bornes du projet ("Design"). 

- Dans ce contexte, les tests fonctionnels ont egalement la 
possibility de forcer, dans chaque composant du systeme, et en 
conformite avec le protocole de coherence assurant I'integrite des 
donnees dans le systeme, les etats de depart des adresses des 
blocs accedes. Cette facilite permet de creer de fagon controlee 
des situations de coherence tres diversifies et complexes sans 
avoir a reconstituer un historique d'execution permettant d'aboutir 
a ces situations. 

- Dans le contexte de la mise au point materielle, I'execution des 
tests fonctionnels se fait en situation reelle sur les processeurs du 
systeme, celui-ci incluant les echantillons physiques du circuit a 
valider. Les tests fonctionnels decrivent des programmes traduits 
en suite destructions a faire executer par les processeurs du 
systeme qui les traduiront eux-memes, si besoin est, en 
transactions adressees au systeme tout entier. 

- Dans ce contexte, les espaces d'adresses sont types. Aucun 
forgage direct sur le format des transactions ou I'etat des blocs 
accedes n'est possible. 

A cause de leur nature differente, il est impossible de reconduire en 
situation reelle sur les echantillons physiques, dans le contexte de mise au 
point, les tests fonctionnels prealablement elabores dans le contexte de la 
verification fonctionnelle et appliques via l'emulateur de Tenvironnement sur 
le modele de type HDL du circuit en projet ("Design") pour la verification de 
sa conception avant sa realisation physique. 
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Sur la figure 1, la reference 1 designe un emulateur de circuit integre 
utilisable notamment pour les circuits integres en projet qui doivent etre 
realises a la demande, et appeles ASIC. L'invention s'applique a tous types 
de circuits integres, par exemple un circuit simple de type microcalculateur 
5 ou un systeme complexe, tel que notamment un systeme multi-noeuds a 
memoire coherente. Les noeuds (Noeud 1,..., Noeud n) de memoire sont 
interconnects par le circuit integre en projet. Un systeme multi-nceuds peut 
etre, par exemple, un ensemble de cartes de circuits integres comportant des 
multiprocesseurs et/ou des entrees-sorties avec antememoire formant une 

10 pluralite de noeuds de communication contenant des memoires, et dont les 
noeuds peuvent emettre des requetes simultanees vers des adresses de 
memoire partagee. Le circuit integre physique ASIC est absent de la figure 1 
et un modele logiciel de ce circuit en projet en langage type HDL de bas 
niveau porte la reference 40 sur la figure 2. L'emulateur 1 communique avec 

15 un ou plusieurs noeuds (Noeud 1,..., Noeud n). Chaque noeud peut 
communiquer avec une station client 50 ou Pensemble des noeuds 
communique avec une seule et meme station client 50. L'emulateur 1 est 
constitue autour d'un systeme de traitement de donnees 10, tel qu'un 
calculateur, qui regoit, en memoire 2, des donnees 20 de specification 

20 fonctionnelle en langage de haut niveau, par exemple C ++ , du modele 40 de 
PASIC du projet a realiser en langage de type HDL. Les donnees 20 
definissent les reponses que doit presenter, sur ses sorties, PASIC, en projet 
a des etats successifs presentes a ses entrees. Un bus d'acces local ou un 
moyen de communication 1B d'acces direct a Temulateur 1 , est ici prevu pour 

25 le gerer. 

D'une fagon generale, comme evoque plus haut, les donnees de 
specification fonctionnelle 20 determinent que I'ASIC en projet a definir par 
son modele de type HDL, presente, a un instant donne, un etat de sortie 
determine, fonction de Petat d'entree instantane qui lui est impose, et fonction 
30 des etats de ses memoires "internes" eventuelles (EMI), usuellement 
existantes dans les ASICs. Par memoire interne, on designe les memoires 
dont le contenu, lisible ou non de Pexterieur de PASIC 40, agit sur Petat 
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d'autres circuits logiques ou sequentiels de I'ASIC 40. Les etats des 
memoires dependent, de fagon generate, des etats anterieurs d'entree de 
I'ASIC, c'est-a-dire de I'historique des sequences de stimuli d'entree et sont 
memorises dans une memoire 962 et dans le coeur 961 de I'emulateur. 
5 L'emulateur 1 comporte egalement, en memoire 9, un logiciel 90 

d'exploitation des donnees 20 de specification fonctionnelle. Le logiciel 90 
comporte des programmes d'elaboration et de validation progressive de 
sequences de test de validation fonctionnelle de I'ASIC en projet. A chaque 
pas d'une sequence de test de validation fonctionnelle, le vecteur ou etat de 

10 sortie, determine en fonction d'un vecteur d'entree actuel et de I'historique, 
est memorise et mis a jour en memoire 91. Cette memorisation peut porter 
sur I'etat des memoires internes (EMI) de I'ASIC en projet, ce qui en pratique 
est necessaire a chaque pas pour calculer les vecteurs de sortie instantanes 
successifs, et surtout elle peut porter sur revolution des etats des memoires 

15 internes de 1'ASIC en fonction des vecteurs d'entree successifs, representant 
les effets de I'historique. 

II y a done une double "modulation" par rapport a une simple bijection 
entree/sortie. 

En effet, d'une part, des vecteurs d'entree differents, appliques a des 
20 instants distincts dans une sequence de stimuli, peuvent avoir des effets qui 
"convergent", c'est-a-dire correspondent a un meme vecteur de sortie, par 
Peffet des etats des memoires internes. 

D'autre part, des vecteurs d'entree identiques, appliques a des 
instants distincts dans une sequence de stimuli, peuvent avoir des effets qui 
25 "divergent" en produisant des vecteurs de sortie differents, par I'effet des 
etats des memoires internes. 

La specification fonctionnelle definie par les donnees 20 peut specifier, 
une table de verite, ou de comportement, correspondant aux fonctions des 
diverses parties ou divers elements de circuit fonctionnels du modele de type 
30 HDL 40 de I'ASIC, mais aussi des plages de retard de propagation a 
respecter entre chaque entree et chaque sortie. La plate-forme de verification 
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verifie ainsi que les reponses de I'ASIC sont situees dans des plages de 
temps de reponse specifiees dans la specification fonctionnelle 20. 

Le logiciel 90 d'elaboration des sequences de test de validation 
fonctionnelle, interprete ainsi les donnees de specification 20 pour fournir, en 
5 tenant compte des etats des memoires internes (EMI) de I'emulateur que 
sont le coeur 961 et les memoires 962 de statut dans la memoire cache 
(antememoire), le vecteur de sortie associe au vecteur d'entree. Le vecteur 
d'entree est fourni par un operateur utilisateur mettant au point le programme 
de test (70). 

10 La reference 30 designe un bus informatique ou un moyen de 

communication, relie soit directement a un terminal d'un utilisateur soit a un 
reseau de transmission de donnees, permettant a un utilisateur de dialoguer 
en mode client-serveur avec I'emulateur 1 a travers un circuit 21 generateur 
de stimuli, traduisant les commandes transmises, par exemple par ,une 

15 interface de communication ("socket"), en stimuli et un circuit 22 gestionnaire 
d'interface, gerant I'interfagage entre la station 50 d'au moins un client, et 
I'emulateur (1). Cet emulateur a ici une fonction d'interface de dialogue 
utilisateur-emulateur (50,1), utilisee dans une premiere etape illustree par la 
figure 1. Comme cela est explique plus loin en regard de la figure 2, le circuit 

20 21 sert a transmettre les stimuli generes par le client utilisateur dans la phase 
de validation fonctionnelle pour les appliquer en entree du modele 40 en 
langage de type HDL de TASIC et a I'emulateur 1, et le circuit 22 est un 
moniteur gerant les interfaces en entree et en sortie entre une station client 
(50) et, d f une part, I'emulateur 1 et, d'autre part, les circuits 11 convertisseurs 

25 de langage evolue vers le langage de type HDL du modele logiciel 40 de 
I'ASIC. Ces deux circuits (21, 22) constituent, avec Tadaptateur 11, 
I'emulateur d'environnement. Une memoire 210 du circuit generateur de test 
21 est prevue pour stacker des sequences de stimuli d'entree, la mise au 
point et la memorisation des sequences d'entree dans leur forme definitive 

30 etant, dans cet exemple, effectuee par le programme. 

Le schema de la figure 1 illustre ainsi un mode de fonctionnement dit 
« emission », dans lequel I'emulateur 1, recevant, par le bus 30, des 
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commandes de I'utilisateur specifiant des sequences de stimuli d'entree, 
emet en retour des stimuli de reponse representant la reponse prevue pour 
le modele logiciel en langage de type HDL 40 de I'ASIC, permettant ainsi de 
mettre au point I'emulateur d'environnement 51 . 

Le programme global de sequences de test 51, stocke cote client 
passera transitoirement dans la memoire 210 d'un circuit 21 generateur de 
stimuli. 

Dans cet exemple, comme I'illustre la figure 1 , I'emulateur 1 est relie 
par le nceud 122 aux circuits 21, 22 a travers deux circuits 11 et 12 
d'adaptation entre les deux langages de programmation, ces circuits 
d'adaptation etant relies en serie et ayant des fonctions d'adaptation 
mutuellement inverses. Le circuit d'adaptation 11, relie directement aux 
circuits 21 et 22, transforme des (commandes de) stimuli provenant de ceux- 
ci, ecrits en langage de haut niveau, ici le langage C ++ , en un langage de bas 
niveau, ici le langage de type HDL, directement interpretable par le modele 
logiciel 40 en langage de type HDL de I'ASIC prevu, c'est-a-dire ici des 
commandes prevues pour etre appliquees, comprises et executees par celui- 
ci. Les stimuli fournis par le circuit 21 en langage C ++ sont transformer en 
langage de type HDL par un port d'entree/sortie 111 du circuit d'adaptation 
C ++ /HDL 11. II peut s'agir de commandes binaires tres elementaires, par 
exemple de portes iogiques, ou de commandes plus elaborees, par exemple 
pour commander un processeur du modele de type HDL 40 de I'ASIC. Ces 
dernieres commandes peuvent, en particulier necessiter une macro- 
commande, c'est-a-dire une sequence de stimuli de commandes 
elementaires. 

Le circuit 12 d'adaptation inverse HDL/C ++ , relie au port 111, sert de 
frontal pour I'emulateur 1, afin que celui-ci, qui utilise le langage C ++ , exploite, 
apres adaptation du langage de type HDL vers le langage C ++ , les stimuli 
initialement traduits en langage de type HDL par le circuit 11. Ce circuit 11 
permet d'exprimer les stimuli dans leur forme reelle d'exploitation, prevus 
pour etre effectivement appliques au modele logiciel 40 en langage de type 
HDL de I'ASIC de la figure 2, a partir du port 111. Cela permet done de tester 
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egalement le bon fonctionnement du circuit 11 d'adaptation C ++ /HDL pour 
chacun des stimuli d'entree. 

Le circuit 11 d'adaptation C ++ /HDL fournit ainsi, par le port 
d'entree/sortie 111, des commandes ou programmes de niveau physique et 
5 logique directement compatibles avec le modele logiciel 40 en langage de 
type HDL de I'ASIC prevu. Ces commandes sont la traduction de 
commandes logicielles ou programmes en langage de plus haut niveau, plus 
abstraites, symboliques, constituant un descripteur specifiant les commandes 
physiques et logiques a appliquer reellement. Ainsi, dans cet exemple, 

10 1'elaboration des sequences de stimuli symboliques du programme de test 
51, en langage de niveau superieur au niveau physique et logique du modele 
40 de I'ASIC, permet de s'affranchir des particulates physiques et/ou de 
langage de programmation interne au modele logiciel de type HDL 40 de 
I'ASiC et facilite done l'6criture de ces sequences. Comme indique, e'est le 

15 circuit 11 d'adaptation C ++ /HDL qui, dans une etape suivante de .celle 
d'ecriture des sequences, effectue la transposition voulue pour I'execution 
pratique des sequences du programme de test 51 . 

Dans le sens oppose, de I'emulateur 1 vers le bus 30, les circuits 
d'adaptation de langage 12 et 11 ont les fonctions inverses de.^celles 

20 respectivement decrites, le circuit 12 transformant les donnees regues de 
I'emulateur 1 et formulees en langage de haut niveau, C ++ , en des donnees 
en langage de bas niveau, de type HDL. Le circuit 11 retransforme les 
memes donnees qui ont ete formulees en langage de bas niveau, e'est-a-dire 
de type HDL, par le circuit 12 en des donnees en langage de haut niveau, 

25 e'est-a-dire C ++ . 

Comme indique ci-dessus, le modele logiciel de type HDL 40 de 
I'ASIC, absent de la figure 1, y est represente fonctionnellement par 
Tensemble reference 140 qui est constitue par I'emulateur 1 avec ici, en 
frontal, le circuit d'adaptation 12, dont un port d'entree/sortie 121 recjoit les 

30 commandes de bas niveau du port 111 et les transmet a I'emulateur 1, par 
un port d'entree/sortie 122, apres les avoir retransformees en un langage de 
haut niveau. En pratique, ici, e'est le meme que celui utilise par le circuit 
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generates de stimuli 21, c'est-a-dire le langage C ++ , mais ('invention 
s'applique egalement au cas ou le langage utilise par le circuit 21 serait, 
certes evolue, mais different de C ++ . Ainsi, I'utilisateur peut dialoguer avec 
I'emulateur 1 au moyen d'un langage de haut niveau, C ++ , les circuits 
d'adaptation de langage 11 et 12 ayant des effets qui s'annulent et qui sont 
ainsi totalement masques fonctionnellement a I'utilisateur, dans la mesure ou 
le circuit 1 1 ne presente pas de defaut de fonctionnement, comme evoque 
precedemment. 

Comme indique plus haut, I'ensemble constitue par I'emulateur 1 et 
son adaptateur de langage 12 constitue un emulateur parfaitement conforme 
au modele logiciel 40 en langage de type HDL de I'ASIC, mais la mise au 
point de ces sequences de stimuli s'effectue par utilisation du langage de 
haut niveau, s'affranchissant des specificites materielles de I'ASIC et des 
specificites des langages de bas niveau de description des circuits integres, 
tel que le langage de type HDL. Cette mise au point permet aussi de verifier, 
en particulier, que le circuit d'adaptation 11, qui sera utilise dans la 
configuration de la figure 2, fournit I'adaptation voulue pour chaque type de 
stimuli du programme de test 70 mis au point. En d'autres termes, la mise au 
point du programme de test 70 s'effectue dans le langage de haut niveau 
C ++ ' mais elle comporte une verification du bon fonctionnement de 
I' « echelle » (circuit d'adaptation 12) qui permettra de faire « descendre » le 
programme de test 70 du langage symbolique C ++ au langage de bas niveau 
de type HDL directement exploitable par le modele de type HDL 40 de 
IASIC. 

Les sequences de test de validation fonctionnelle sont mises au point 
par un utilisateur relie au bus 30 en envoyant les stimuli d'entree et recevant 
en retour des reactions du logiciel 90 d'exploitation en memoire 9, qui signale 
des defauts eventuels dans ('elaboration du programme global de sequences 
de test, et permet leur correction. Une fois les sequences de test de 
validation fonctionnelle mises au point, I'ensemble de ces dernieres 
constituant le programme de test 51, est recopie dans la memoire 
d'exploitation 210 du circuit generateur de stimuli 21 . 
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La figure 2 illustre une phase suivante de fonctionnement, dite de 
« verification », dans laquelle est effectue un test de validation fonctionnelle 
du modele logiciel 40 de I'ASIC en langage de type HDL. Dans cette phase, 
sous la commande des stimuli du programme de test 51 emis par la memoire 
5 210, les divers etats -d'entrees soumis au modele logiciel de I'ASIC, sont 
egalement soumis, en entree, a I'emulateur 1 qui elabore, par le programme 
90 en dynamique, les sorties previsibles qui apparaissent successivement en 
sortie 230 de I'emulateur 1, en reutilisant precisement la meme specification 
fonctionnelle 20 que celle utilisee pour le mode « emission ». Les sorties de 
10 I'emulateur 1 evoluent en synchronisme avec I'etat, reel, des sorties du 
modele logiciel 40 de I'ASIC en langage de type HDL, ce qui permet de 
detecter toute discordance du fonctionnement cible prevu, defini par 
I'emulateur 1. , 

s 

Sur la figure 2, I'emulateur 1 dialogue directement avec un circuit 

is generateur de stimuli 21 et un circuit moniteur d'interface 22 pour chaque 
noeud du modele logiciel, puisque 1'adaptation de langage C ++ /HDL effectuee 
par le circuit d'adaptation 11a ete v6rifiee selon le schema de la figure- 1 . Le 
circuit d'adaptation inverse 12 est done omis. Le modele logiciel 40 de I'ASIC 
en langage de type HDL est alors relie au port 111 du circuit d'adaptation 11 

20 (dessine retourne), servant de frontal d'adaptation de langage. En d'autres 
termes, le modele logiciel 40 de I'ASIC en type HDL de la figure 2 remplace 
I'ensemble 140 constitue, sur la figure 1, par I'emulateur 1 avec son circuit 
frontal d'adaptation 12. L'emulateur 1 de la figure 2 sert alors a controler, par 
comparaison, les reponses reelles du modele logiciel 40 de I'ASIC en 

25 langage de type HDL a celles prevues par I'emulateur 1 . 

Le port 112 est ici represents eclate en un port d'entree 112A, relie au 
circuit generateur de stimuli de test 21 par une liaison 25, et un port de sortie 
112B relie a un comparateur 23. Le modele de type HDL de I'ASIC 40 
presente ainsi, pour son environnement, une interface 112A, 112B de 

30 dialogue dans le langage de haut niveau, ici C ++ , utilise par les autres circuits 
1, 21, 22 et 23. 
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L'emulateur 1 est alors relie en entree a la - liaison 25, done 
directement en parallele sur le port d'entree 112A pour recevoir, tout comme 
le modele de type HDL 40 de I'ASIC a travers le circuit d'adaptation 11, les 
sequences de stimuli memorisees en memoire 210 correspondant au 
5 programme de test de validation 70 en langage de haut niveau, qui a ete mis 
au point selon le schema de ia figure 1. L'emulateur 1 fournit en reponse, au 
comparateur 23, un etat, ou stimuli, ou encore vecteur, de sortie, fonction 
des donnees de specification 20, qui est considere comme etant I'etat de 
sortie cible, ou de reference, associe a I'etat d'entree. II s'agit done, parmi les 

10 etats de sortie previsibles, de celui qui est determine ou selectionne d'apres 
I'etat d'entree fourni au verificateur 960. Nous expliciterons ulterieurement le 
role du verificateur 960. 

Le modele le modele logiciel en langage HDL de I'ASIC fournit aussi, 
de son cote, un etat de sortie qui est transforms par le circuit d'adaptation 1 1 

15 pour etre presente dans le langage de haut niveau C ++ , cet etat de sortie 
etant en principe identique a celui prevu par l'emulateur 1. Le circuit 
comparateur 23 a ete dessine pour illustrer la comparaison des sorties qu'il 
regoit et il fait en realite fonctionnellement partie de Temulateur 1. Le 
comparateur 23 compare les etats de sortie du modele de type HDL 40 de 

20 I'ASIC, regus par le port 112B, et les stimuli de sortie fournis par le 
verificateur 60 de Temulateur 1 pour detecter une eventuelle discordance et 
la signaler a Tutilisateur client. En pareil cas, cela indique un defaut de 
conformite du modele logiciel 40 en langage de type HDL de I'ASIC avec la 
specification 20, du a un defaut de conception ou a une erreur de 

25 fonctionnalite au niveau de Tensemble modele ASIC-programme de test. La 
sortie du comparateur 23 remplit un fichier enregistrant des notifications 
d'erreurs en cas de comparaison non concluante. Le circuit moniteur 
d'interface 22 et le circuit generateur de stimuli 21 regoivent les sorties du 
modele de type HDL pour permettre de tenir compte des reponses 

30 anterieures dans la generation de stimuli et pour le generateur 21 generer 
des fichiers de trace. 
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Comme evoque plus haut, le client peut, en variante ou en 
complement, ecrire et fournir tout ou partie de la specification fonctionnelle 
20 sous la forme d f un programme dans un langage de bas niveau, tel que 
defini plus haut, remplagant ou completant un programme homologue de 
5 haut niveau. Dans le cas ou la specification fonctionnelle 20 est ainsi definie 
au total dans deux langages differents par leurs niveaux ou autre, le client 
utilisateur commande alors I'emulateur 1 pour que le logiciel 90 d'elaboration 
de test, prevu a cet effet, effectue une co-simulation, ou co-emulation, par 
synchronisation d'execution des deux programmes de specification. 

10 La figure 3 reprend les elements representes sur la figure 2, avec, 

toutefois, une duplication du circuit d'adaptation du langage 11i 
respectivement 11 2 pour un premier et un second nceud et des circuits 21 1t 
21 2, 22i, 22 2 et du bus 30 d'interface de liaison avec les clients utilisateurs, 
pour un fonctionnement multi-noeud (Noeud 1, Noeud 2) et multi-utilisateur 

15 (Client 1, Client 2). 

La figure 3 represente un mode de realisation de la plate-forme de 
verification de I'invention dans laquelle on inclut le modele d'elaboration de 
prediction, ou emulateur 1, constituant le verificateur permettant de verifier la 
conformite du modele de type HDL de TASIC developpe par rapport a la 

20 specification fonctionnelle et aux tests elabores pour verifier cette 
specification fonctionnelle. 

Dans la suite du document, ROUTEUR designe : soit le modele 
logiciel en langage de type HDL du circuit en projet, qui est un circuit routeur 
permettant le routage d'information dans un systeme multi-noeuds, soit 

25 I'emulateur de ce circuit en mode emission. 

Une transaction du systeme s'execute de la fagon suivante. 
Le contexte d'execution de I'emulateur du ROUTEUR est un systeme 
multi-noeuds a memoire coherente, ces noeuds etant interconnects par le 
ROUTEUR. Un systeme multi-noeuds peut etre, par exemple un ensemble 

30 de cartes de circuits integres comportant des multiprocesseurs, et/ou des 
entrees-sorties formant une pluralite de noeuds de communication contenant 
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des memoires et dont les nceuds peuvent emettre des requetes simultanees 
vers des adresses de memoire partagee. 

Les composantes d'une transaction sont les suivantes. 

Un noeud peut emettre des requetes dites primaires, de type lecture, 
5 ecriture, invalidation. Ces requetes recevront une ou plusieurs reponses dites 
primaires. Le ROUTEUR peut etre amene, pour traiter une requete primaire 
emise par un premier noeud P, a generer une ou plusieurs requetes dites 
secondaires vers des noeuds S distincts du premier noeud P. Chaque noeud 
S emettra une ou plusieurs reponses dites secondaires. L'ensemble de ces 
10 reponses secondaires servira au ROUTEUR a emettre la reponse primaire. 

L'ensemble {requete et reponse(s) primaire(s), requete(s) et 
reponse(s) secondaire(s)} constituent une transaction. 

Les noeuds disposent d'une antememoire pour memoriser les blocs de 
memoire utilises contenant, soft des adresses, soit des donnees. 
15 Le ROUTEUR dispose d'une antememoire (appelee DIRECTORY 

dans la suite du document) pour memoriser les blocs utilises par les noeuds 
d'apres leur adresse. Pour une adresse utilisee par un ou plusieurs noeuds, 
un vecteur de presence est gere avec, par noeud, un temoin de presence. 
Cette memoire cache permet de iimiter la generation des requetes 
20 secondaires aux noeuds utiles pour Texecution de la transaction (exemple : 
invalidation propagee vers les noeuds qui ont le temoin de presence valide) 

Le ROUTEUR peut etre amene a traiter plusieurs transactions 
relatives au rneme bloc memoire. Cet ensemble de transactions est appele 
collision. Le ROUTEUR les prend en compte de maniere serielle. L f ordre 
25 dans lequel le ROUTEUR les prend en compte est appele ordre de 
serialisation. 

Pour chaque requete primaire, le ROUTEUR est amene a determiner 
I'etat final du bloc memoire. 

[cas a] Si la determination de cet etat final par le ROUTEUR requiert 
30 une ou plusieurs {requete, reponses(s) secondaire(s)}, la transaction passe 
en section critique (jusqu'a la reception des reponses secondaires); visible 
de I'emulateur. 
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[cas b] Dans le cas contraire, Pemulateur n'a connaissance de la 
decision du ROUTEUR qu'au travers des reponses primaires. 

La difficulty pour I'emulateur de suivre Pactivite du ROUTEUR vient du 
fait que les transactions repondant au second cas [cas b] ont leur point de 
5 serialisation non visible par I'emulateur. 

Par contre, les transactions repondant au premier cas [cas a] ont leur 
point de serialisation visible de I'emulateur, et offrent a Pemulateur une aide 
importante dans le suivi de Pactivite du ROUTEUR. 

L'emulateur en mode verification va effectuer des predictions. 
10 Pour suivre Pactivite du ROUTEUR en cas de collision, Pemulateur doit 

predire Pensemble des ordres de serialisation possibles et pertinents 
qu'amenent cette collision. 

La generation des predictions consiste en la production, pour chaque 
cas de serialisation envisage, des profits des requetes secondares, 
is reponses primaires et secondaires qui devraient apparaTtre aux interfaces du 
ROUTEUR. 

L'observation d'une sortie du ROUTEUR (requete secondaire, 
reponse primaire) est confrontee aux profils des predictions. 
En cas de non-correspondance, la prediction est rejetee. % 
20 Si aucune prediction ne repond a Pobservation, Pemulateur signale 

une erreur. 

La programmation objet a permis : d'une part, de structurer Pemulateur 
de ROUTEUR en un ensemble de classes specialisees et, d'autre part, de 
simplifier le traitement par la localisation et specialisation de ces traitements 
25 a chaque instance de chaque classe, 

Les classes suivantes sont utilisees par Pinvention : 

• La classe "Txnld". 

Une instance (T) de cette classe assure le suivi de Pexecution d'une 
transaction. 

30 Cette instance T gere une collection d'hypotheses d'execution (qui 

sont des instances de la classe TxnldHypothesis). 
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Une hypothese d'execution est conservee tant que les observations 
des sorties du ROUTEUR sont conformes aux predictions faites par cette 
hypothese. 

L'execution de cette instance T est consideree comme correcte tant 
5 qui! existe au moins une hypothese vivante. 

Cette instance T est en charge de verifier la fin d'execution de la 
transaction (c'est-a-dire qu'il existe des hypotheses vivantes ayant observe 
toutes les sorties du ROUTEUR predites). 

• La classe "TxnldHypothesis". 

10 Une instance (TH) de cette classe assure le suivi d'une hypothese 

d'execution d'une transaction. 

Cette instance (TH) gere une instance de la classe Syst_Xaction. 
Cette instance (TH) est en charge de controler que les observations 
des sorties du ROUTEUR sont conformes aux predictions de cette 
is hypothese. 

L'instance (TH) est en charge de gerer les reponses aux requetes 
secondaires. 

• La classe "Syst__Xaction". 

Une instance (SX) de cette classe memorise les informations relatives 
20 a la requete primaire, et a la (aux) requete(s) secondaire(s) predite(s) par 
1'hypothese attachee. 

Cette instance (SX) memorise egalement des marques d'execution de la 
transaction. 

• La classe "CoIlisionScenario". 

25 Une instance (CS) de cette classe gere une serialisation possible de 

transactions en collision. Cette instance (CS) gere egalement le cas de non- 
collision (c'est-a-dire le cas d'une transaction en cours sur un autre bloc 
memoire). 

Pour chaque transaction concernee, une hypothese d'execution de 
30 cette transaction est attachee a Tinstance (CS). 
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L'instance (CS) gere une liste ordonnancee d'instances de la classe 
"CollisionElement". 

Cet ordonnancement reflete la serialisation des transactions en 
collision. 

• La classe "CollisionElement". 

Une instance (CE) de cette classe gere l'etat d'execution d'une 
hypothese d'execution d'une transaction dans un contexte de collision. 
Les principaux etats d'execution sont : 

- ASLEEP : aucune observation de sorties du ROUTEUR n'a ete faite 
pour cette hypothese. 

-PREDICTED: toutes les predictions pour assurer le suivi de 

I'hypothese sont elaborees. 
-WTSNOOP, WTCMP : la transaction est en section critique, en 

attente d'une (de) reponse(s) secondaire(s). v 
-WTTRANS : aucune observation de sorties du ROUTEUR ne peut 

avoir lieu pour cette hypothese. 
-COMPLETED : la transaction est terminee. 

Pour les etats ASLEEP et WTTRANS, aucune prediction n'a ete 
realisee. u 

L'etat WTTRANS est atteint pour une hypothese dont la serialisation 
devra attendre la fin de section critique d'une autre transaction. 

L'instance (CE) gere egalement une instance de la classe 
"Director/Entry". 

• La classe "DirectoryEntry". 

Une instance (DE) de cette classe gere l'etat (ESI) d'un bloc memoire, 
ainsi que le vecteur de presence de ce bloc dans les noeuds peripheriques 
du ROUTEUR. 

Ces informations refletent celles dont le ROUTEUR dispose pour 
gerer le bloc. 

Chaque indice du vecteur de presence (ou temoin de presence) 
indique : 

- soit la presence certaine du bloc dans le noeud attache ; 
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- soit la presence potentielle du bloc dans le noeud attache. 

Dans certaines occasions (par exemple I'execution de certains types 
de transaction dans un contexte de collision), le ROUTEUR peut effacer ou 
maintenir un temoin de presence, sans indication de cet evenement au 
5 travers de sorties specialisees observables par I'emulateur. 

• La classe "Transition". 

Cette classe gere ('activation d'une transition relative a un evenement 
(EV) (requete primaire, ou reponse secondaire dans un contexte de section 
critique) et a une instance DE. 
10 La transition a activer est recherchee dans une table (instance de la 

classe TransitionTable). 

Cette activation conduit a la mise a jour de I'instance (DE) et a 
Tactivation d'une instance de la classe "TransitionAction". 
La classe "TransitionTable". 
15 Cette classe decrit de fagon generique toutes les transitions 

autorisees par le protocole. 

Pour chaque etat d'une instance (DE), pour chaque type d'evenement 
EV, sont specifies comment mettre a jour instance DE et I'instance de la 
classe "TransitionAction" a activer. 
20 • La classe "TransitionAction". 

Cette classe englobe les differents types d'action generiques a 
accomplir suite a la reception d'un evenement EV. 

Ces actions prennent en parametres la requete primaire, le contenu 
de Tinstance DE associee. 
25 Parmi ces actions, on trouve entre autres : 

- la propagation d'invalidation vers les noeuds ayant le temoin de 
presence dans Tinstance DE; 

- la propagation vers le noeud detenteur du bloc memoire cible, d'une 
lecture ou mise a jour de ce bloc; 

30 - la propagation d'une reponse vers le noeud initiateur de la requete 

primaire. 
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Le terme « propagation » reflete la generation des predictions qui 
seront confrontees aux observations des sorties du ROUTEUR. 

• La classe "Directory". 

Une instance (D) de cette classe gere les instances DE associees aux 
5 blocs memoires presents dans les filtres du ROUTEUR. 

Une instance DE indique un etat stable du bloc si aucune transaction 
n'est en cours d'execution sur ce bloc. 

Dans le cas contraire, I'entree DE memorise les instances T en cours 
d'activite sur ce bloc. 
10 Le prochain etat de cette instance DE est alors en cours devaluation 

dans les differentes instances CE/CS associees a ces instances T. 

• La classe "VerifierCore". 

Une instance (VC) de cette classe gere I'ensemble de I'activite* y 
VC re9oit les stimuli (requetes/reponses primaires/secondaires), cree 
is les instances T a la reception des requetes primaires, soumet les stimulis a 
ces instances et les detruit en fin de transaction. 

Les algorithmes du ROUTEUR realisent les fonctions suivantes: 

• Fonction de generation des predictions : 

Sur observation d'une requete secondaire ou reponse primaire (emise 
20 par le routeur) relative a une transaction t, tous les scenario pertinents (i.e. 
differents ordres de serialisation) mettant en jeu cette transaction et celles en 
collision sont evalues. 

• Fonction d'elimination de predictions : 

Une prediction est ecartee (i.e. I'instance CS de la classe 
25 CollisionScenario est detruit) si, dans cette instance CS, I'etat de Pinstance 
cible de la classe "CollisionElement" n'est pas compatible avec I'observation, 
ou si, dans cette instance CS, la prediction geree par ('instance cible de la 
classe "TxnldHypothesis" n'est pas conforme a I'observation (exemple : non- 
conformity entre profit de I'observation etde la prediction). 
30 • Fonction de re-ajustement de mauvaise prediction : 
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Dans certaines occasions (execution de certains types de transaction 
dans un contexte de collision), le ROUTEUR peut effacer ou maintenir un 
temoin de presence dans son antememoire (Directory), sans indication de 
cet evenement au travers de sorties specialisees observables par 
5 I'emulateur. Par defaut, I'emulateur de ROUTEUR genere des predictions 
avec temoin de presence efface. 

Si une observation montre que le choix inverse serait plus judicieux, 
les instances de la classe "CoIlisionScenarios" concernees sont re-evaluees 
en maintenant le bit de presence en question. 
10 • Fonction de reduction du nombre d'hypotheses valides : 

Pour assurer le suivi d'une collision, Temulateur de ROUTEUR est 
amene a gerer un nombre distances de la classe "CollisionScenario" qui 
peut devenir eleve. 

Certains cas de collision peuvent produire les memes observations 
is pour les serialisations obtenues en permutant I'ordre de prise en compte des 
transactions concernees. 

Pour limiter le nombre d'instances de la classe "CollisionScenario", 
I'emulateur de ROUTEUR detecte dans chaque instance "CollisionScenario", 
les sous-ensembles d'instances de "CollisionElement" dans I'etat 
20 COMPLETED ou PREDICTED, pour lesquels I'etat de ('instance DE attachee 
n'a pas evolue. 

Ces sous-ensembles sont re-ordonnances. Les doublons sont 
eiimines 

• Fonction de terminaison des collisions : 
25 L'emulateur de ROUTEUR detecte, sur Tensemble des instances de la 

classe "CollisionScenarios" relatifs a une collision, les situations ou les n 
premieres instances de la classe "CollisionElements" sont relatifs aux 
memes transactions et aboutissent a des etats de Tantememoire (Directory) 
compatibles. 

30 Ces instances de la classe "CollisionElements" sont alors detruites, 

I'instance de la classe "Director/Entry" correspondante dans la Directory est 
mise a jour. 
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[-'organisation de I'emulateur ainsi defini a permis de simplifier le 
traitement par la localisation et la specialisation de ces traitements a chaque 
instance de chaque classe, d'isoler une transaction, une collision, et de 
specialiser les classes pour permettre une genericite des traitements. 
5 L'isolation d'une transaction, d'une collision est obtenue par le fait 

qu'une transaction est modelisee au travers d'une entree dans la table des 
transactions. Cette entree consiste en un pointeur vers une instance T de la 
classe Txnld. Cette instance pointe vers des instances TH de la classe 
"TxnldHypothesis". Chaque instance TH pointe vers une instance SX de la 
10 classe "SystJXaction", vers une instance CS de la classe 
"CollisionScenario", et dans cette instance de la classe "CollisionScenario", 
vers une instance CE de la classe "CollisionElement". 

Cette instance CE pointe vers une instance DE de la classe 
"DirectoryEntry". 

is Les avantages de cette organisation sont, d'une part, Tetancheite 

entre les traitements des transactions et, d'autre part, le suivi aise d'une 
transaction, d'une collision (objets lies par pointage). 

L'etancheite entre les traitements des transactions assure une 
robustesse des traitements par rapport a la charge, une facilite de f mise au 
20 point (un probleme lie au traitement d'une collision est independant de la 
charge et peut done etre analyse en rejouant uniquement cette collision). 

Le suivi aise des traitements allege les phases de mise au point et le 
suivi du programme. 

La specialisation des classes et la genericite des traitements sont 
25 dues au fait que les classes "Transition", "TransitionTable" et 
"TransitionAction" sont specialisees dans le traitement des transitions et 
gerent de maniere independante une part tres importante du protocole. Elles 
peuvent etre facilement adaptees a d'autres protocoles de type MESI. 

Les classes "CollisionScenario", "CollisionElement" sont specialisees 
30 dans le traitement des ordres de serialisations. Les seules informations 
manipulees sont les etats possibles des transactions (etat final du bloc 
predictible, section critique necessaire) et les etats de Tantememoire 
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(Directory) produits par les transitions. Des algorithmes de limitation du 
nombre de "CollisionScenario", independants du protocole, peuvent etre 
appliques, bases sur les etats finaux fournis par les transitions. 

Les classes "Txnld", "TxnldHypothesis", "Syst_Xaction" sont 
5 specialisees dans le suivi de I'execution d'une transaction (memorisation des 
requetes secondaires en cours t divers temoins d'execution, prise en compte 
des reponses secondaires) et dans la comparaison des profils des 
predictions et observations. 

Les classes"Directory" et "DirectoryEntry" sont specialisees dans la 
io gestion de la memoire cache (antememoire). 

Tous les protocoles de memoire cache peuvent etre facilement 
integres. 

La figure 4 represente ['architecture interne du verificateur. 

Chacun des clients emet, a travers des commandes d'appels JCALL, 

15 des requetes de tests du modele de type HDL 40 du circuit ASIC. Ces 
commandes sont transmises au generateur de stimuli 21 et moniteur 
d'interface 22 qui les envoie, d'une part, vers le circuit verificateur de 
I'emulateur 1 pour elaborer des predictions de reponses du modele de 
TASIC, d'autre part, vers le circuit 11 convertisseur d'un langage evolue en 

20 C ++ vers un langage de bas niveau de type HDL de description du hardware 
du circuit ASIC et, a travers ces convertisseurs, vers le modele de type HDL 
du circuit ASIC. 

Les requetes sont regues par les interfaces de traitement XSEqGen 
(figure 4) du verificateur 960 et egalement utilisees dans les circuits 21, 22 

25 generateurs de stimuli pour transmettre et verifier les paquets de requete. 
Deux instances sont utilisees pour chaque interface du verificateur 60, une 
premiere recevant les requetes a destination de Temulateur 1 agit comme 
repondeur, I'autre transmettant les requetes de Temulateur agit comme un 
emetteur mais toutes deux sont identiques. 

30 Le noyau verificateur 961 est le composant central elaborant les 

predictions en fonction des adresses, dans le repertoire 962 (SF/ED) de la 
memoire, du vecteur de presence des stimuli de reponse et des paquets 
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regus representant les stimuli d'entree. L'organisation du noyau 961 de 
verification est realisee autour de classes instanciees sous forme d'objets. Le 
noyau verificateur 961 memorise des registres de configuration pour le 
routage des requetes non coherentes, la determination de la localisation de 
5 la memoire pour les requetes coherentes, les gestions des domaines. Le 
noyau de verificateur inclut un tableau 9610 pour les transactions en cours 
d'utilisation a I'interieur du verificateur. Chaque entree du tableau pointe vers 
une instance de la classe TXNID qui represente la transmission de la 
transaction a I'interieur du verificateur. 

io Chaque fois qu'une requete d'entree coherente est regue par le 

verificateur 961, une structure temporaire est creee pour predire quelle 
transaction du repertoire sera utilisee comme adresse bloc et quelles seront 
les sorties predites pour le modele du circuit ASIC en test vers le circuit de 
transmission XSEqGen. Cette structure temporaire est une instance de la 

15 classe « element de collision ». Le traitement d'une transaction utilise 
^ toujours cette structure meme si aucune collision avec une autre transaction 

n'est detectee. 

Pour executer la prediction, I'entree de repertoire (instance de la 
classe entree de repertoire) utilisee par ce bloc est copiee et utilisee par 

20 (Instance element de collision de la classe "CollisionElement". La prediction 
de I'execution est traitee par I'usage des instances des classes "Transition" 
et des classes « action de transition » ("TransitionAction"). Les instances des 
classes « Transition » et « action de transition » font partie de la specification 
fonctionnelle contenue dans la memoire (2). Les instances de cette classe 

25 sont creees au moment de la simulation et fournissent des methodes 
fonction de la generation de transition d'etat et de la generation de requetes 
envoyees ou de reponses fournies par le verificateur. Ces methodes sont 
activees par les instances d'elements de collision de la classe 
"CollisionElement". 

30 Le fonctionnement du noyau repose sur ['utilisation d'un certain 

nombre de classes qui sont utilisees, d'une part, pour decrire des ressources 
et, d'autre part, pour decrire des methodes utilisees par les instanciations de 
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cette classe dans un objet. Cette structure sous forme de classes permet de 
realiser une plate-forme de verification faciiement modifiable en instanciant 
de nouveaux objets, permettant ainsi de decrire de nouvelles procedures de 
tests ou de nouvelles reponses a des stimuli regus par de nouvelles 

5 fonctionnalites ajoutees sur le circuit. On peut ainsi aisement adapter la 
plate-forme a de nouveaux circuits developpes. 

II doit etre clair pour le lecteur que lorsqu'on utilise le terme HDL ou 
modele de type HDL, on fait reference a un langage de description d'un 
circuit integre qui est considere comme etant de plus bas niveau par rapport 

10 au langage C++ dit de haut niveau, mais ceci ne doit pas etre interprets 
limitativement car invention s'applique egalement a tout autre langage de 
description d'un circuit integre, tel que par exemple VHDL ou verilog ou 
encore tout autre. 

On congoit que la presente invention peut etre mise en oeuvre selon 
15 d'autres formes specifiques, sans sortir de son domaine d'application tel que 
revendique. Par consequent, la presente description detaillee doit etre 
consideree comme etant une simple illustration d'un cas particulier dans le 
cadre de ('invention et peut done etre modifiee sans sortir du domaine defini 
par les revendications jointes. 

20 
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REVENDICATIONS 

1 . Procede de verification fonctionnelle d'un modele logiciel (40) d'un 
circuit integre a la demande (ASIC), en langage de bas niveau (tel que par 
exemple de type HDL) traitant de fagon separee I'etablissement du modele et 

5 la mise au point des tests de verification fonctionnelle a appliquer au modele 
du circuit pour constituer une plate-forme de verification comportant les deux 
etapes suivantes : 

- constitution d'un emulateur autonome (1) de circuit obtenu en 
remplagant le modele en langage de bas niveau (de type HDL) de description 

10 physique du circuit en projet a valider, par une description abstraite de haut 
niveau (par exemple C ++ ) generant des structures de donnees de reponse 
conformes a la specification fonctionnelle (20) du projet en fonction des 
stimuli regus, ce mode etant dit « mode emission », 

integration du modele logiciel (40) en langage de bas niveau (de 

15 type HDL) du circuit resultant du projet dans une plate-forme de verification, 
et constitution du branchement de I'emulateur autonome (1) de circuit, 
precedemment validee, en parallele sur les interfaces du modele logiciel (40) 
du circuit, et du branchement d'un emulateur d'environnement (1 1 ,21 ,22), et 

- utilisation de cette plate-forme comme reference pour la 
20 validation des donnees de reponses emises par le modele logiciel (40) du 

circuit, ce mode etant dit « mode verification ». 

2. Procede selon la revendication 1 , dans lequel : 

• un utilisateur elabore, au moyen d'un systeme de traitement de 
donnees, la configuration de simulation autonome (1) 

25 correspondant au modele logiciel (40) de I'ASIC au moyen de la 

specification fonctionnelle (20), 

• Tutilisateur ecrit, a partir de la specification fonctionnelle (20), et 
memorise, dans une plate-forme de test (21 , 22, 23) de modeles de 
circuits integres, un programme (51) de test du modele (40) de 

30 I'ASIC, comportant des sequences de stimuli d'entree a fournir au 

modele logiciel (40) de TASIC, auxquelles la configuration de 
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simulation autonome (1) fait corresponds, en fonction de la 
specification fonctionnelle (20), des sequences de stimuli de sortie, 
• Tutilisateur relie ensemble et active la configuration de simulation 
autonome (1) et la plate-forme de test (21, 22, 23), et 
5 • il observe les stimuli de sortie du modele de type HDL (40) de 

I'ASIC pour valider fonctionnellement I'ensemble constitue par le 
modele logiciel du circuit ASIC et le programme de test de 
validation (210), et ainsi valider le modele logiciel (40) par rapport a 
la specification fonctionnelle (20). 
10 3. Procede selon Tune des revendications 1 et 2, dans lequel, la 

configuration de simulation autonome (1) communiquant avec Putilisateur 
pour commander Pactivation de modeles, prealablement etablis et 
memorises, de sequences de stimuli d'entree definis dans un langage de 
programmation de haut niveau, et commande ('activation de programmes 
is associes (90) de validation progressive de sequences de test determinees a 
partir des modeles. 

4. Procede selon Tune des revendications 1 a 3, dans lequel 
I'utilisateur ecrit et fournit la specification fonctionnelle (20) dans un langage 
de programmation de bas niveau, specifiant des modeles fonctionnels de 

20 circuits. 

5. Procede selon Tune des revendications 1 a 4, dans lequel 
I'utilisateur fournit la specification fonctionnelle (20) sous la forme d'un 
programme en langage de bas niveau, de modeles (de type HDL) 
fonctionnels de circuits, et d'un programme en langage de haut niveau, de 

25 modeles fonctionnels ((C++) symboliques de circuits), et il commande la 
configuration de simulation autonome (1) pour effectuer une co-simulation 
par synchronisation d'execution des deux programmes de specification. 

6. Procede selon Tune des revendications 1 a 4, dans lequel la plate- 
forme de test verifie que les reponses du modele logiciel de I'ASIC sont 

30 situees dans des plages de temps de reponse specifiees dans la 
specification fonctionnelle (20). 
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7.. Plate-forme de verification de modele logiciel de circuit integre a la 
demande (ASIC), caracterise par le fait quelle comporte des moyens de 
traitement de donnees permettant a un client de selectionner des modeles de 
test engendrant des stimuli d'entree de PASIC, ces moyens de traitement 
5 etant agences pour lire des elements (20) de specification fonctionnelle de 
I'ASIC, et comportant des programmes (90) agences pour elaborer un 
programme de test (51) de validation fonctionnelle constitue de stimuli de 
sortie a partir des stimuli d'entree et des elements de specification 
fonctionnelle (20). 

10 8. Plate-forme de verification selon la revendication 7, comportant une 

bibliotheque de modeles fonctionnels de blocs de circuits pour ASIC et des 
moyens de selection des modeles par un fichier de definition de la 
configuration pour constituer un modele correspondant a la specification 
fonctionnelle de I'ASIC integre a la definition de son environnement. 

15 9. Plate-forme de verification selon Tune des revendications 7 ; et 8, 

dans laquelle il est prevu, dans une liaison le reliant au client, deux circuits 
en serie d'adaptation de langage de programmation (11, 12) agences pour 
transformer des commandes en langage de haut niveau (C ++ ), utilise par le 
client, en commandes en langage de bas niveau (de type HDL), exploitables 

20 par le modele de I'ASIC, et pour, respectivement, retransformer les 
commandes en langage de bas niveau en commandes en langage de haut 
niveau. 

10. Plate-forme de verification selon une des revendications 7 a 9, 
caracterise par le fait qu'elle comporte des moyens (90, 10) d'executer ses 

25 traitements en meme temps que la simulation qu'il peut interrompre des la 
detection d'une erreur au moment meme de Papparition de Terreur. 

11. Plate-forme de verification selon une des revendications 7 a 10 
caracterise par le fait que les elements (20) de specification fonctionnelle 
sont constitues d'une table de verite, ou de comportement, correspondant 

30 aux fonctions des diverses parties ou divers elements de circuit fonctionnels 
du modele logiciel (40) de I'ASIC, et des plages de retard de propagation a 
respecter entre chaque entree et chaque sortie. 
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12. Plate-forme de verification selon une des revendications 7 a 11, 
caracterise par fe fait qu'elle dispose d'une antememoire (962) pour 
memoriser les blocs utilises par les noeuds d'apres leur adresse et des 
moyens de gerer, pour une adresse utilisee par un ou plusieurs noeuds, un 

5 vecteur de presence avec un temoin de presence par nceud. 

13. Plate-forme de verification selon une des revendications 7 a 12, 
caracterise par le fait que les programmes (90) sont orientes objet et 
I'emulateur est structure en un ensemble de classes permettant de gerer une 
collection d'hypotheses d'execution d'une transaction sur un bloc memoire du 

10 modele logiciel, et de gerer egalement les transactions en collisions, c'est-a- 
dire utilisant concurremment un meme bloc memoire. 

14. Plate-forme de verification selon une des revendications 7 a 13 
caracterise par le fait que les algorithmes des programmes (90) de 
Pemulateur realisent les fonctions suivantes : generation des predictions, 

15 elimination des predictions, re-ajustement de mauvaise prediction, reduction 
du nombre d'hypotheses valides et terminaison de collisions. 

15. Plate-forme de verification selon une des revendications 7 a 14 
caracterise par le fait qu'elle est utilisee en emulateur de circuit routeur, de 
circuit a antememoire ou de circuit routeur a antememoire. 

20 16. Plate-forme de verification, selon une des revendications 7 a 15, 

pour tester un modele logiciel de circuit integre a la demande (ASIC), 
caracterisee en ce qu'elle comporte un emulateur d'ASIC (1) pour 
commander un comparateur (23) prevu pour recevoir des valeurs generees 
par le modele logiciel de circuit ASIC teste, sur reception de stimuli envoyes 

25 par au moins un circuit (21) generateur de stimuli, memorisant le programme 
de test, une interface (11) de traduction des stimuli d'un langage elabore vers 
un langage de bas niveau correspondant a celui du modele logiciel, et des 
moyens de validation de la verification en cas de detection de collision par le 
comparateur (23). 

30 17. Plate-forme de verification selon une des revendications 7 a 16, 

caracterisee en ce que les moyens de selection de la reponse a des stimuli 
dependants de la constitution des circuits testes sont constitues d'un modele 
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elabore grace a des moyens de selection, parmi une bibliotheque, de 
modeles fonctionnels associant, a chacun des modeles, les reponses a un 
stimulus donne, le modele correspondant a la constitution du circuit a tester. 

18. Plate-forme de verification selon une des revendications 7 a 17, 
5 caracterisee en ce qu'elle comporte des moyens (7) de memorisation des 

reponses ainsi selectionnees pour constituer un modele de test (70) a 
appliquer au circuit teste lors de la reception de stimuli. 

19. Plate-forme de verification selon une des revendications 7 a 18, 
caracterisee en ce que chaque transaction est constitute, au niveau de 

10 chaque interface, d'un paquet requete et d'un ou plusieurs paquets reponses 
associes, dont les valeurs des parametres et/ou les contraintes temporelles 
d'emission des paquets peuvent etre forcees a partir du programme de test 
fonctionnel execute par I'emulateur de I'environnement, qui traduit de fagon 
adequate Tensemble de ces parametres lors de remission des paquets aux 

is bornes du modele logiciel du projet. 

20. Plate-forme de verification selon la revendication 14, caracterisee 
en ce que la generation des predictions est effectuee par I'emulateur du 

circuit sans avoir a prelever d'informations supplementaires sur le 

• *' ■ 

fonctionnement interne du circuit en projet. 
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Figure 3 : Mode "Verification" 
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Fig ure 4 : Architecture interne Verificateur 
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